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CASH FLOW AGGREGATION SYSTEM AND METHOD 

FIELD OF THE INVENTION 

[0001] The present invention relates generally to investment services, 
systems, and methods. More particularly, the present invention relates to cash 
flow systems and methods. 

BACKGROUND OF THE INVENTION 

[0002] Introduction of the mortgage backed security (MBS) has made the 
dream of owning a home possible for a much larger number of individuals. 
Frequently, when a borrower takes out a loan to purchase a home, that loan is 
subsequently pooled with other loans and used to create an MBS. The MBS is 
an investment instrument that can be sold to investors in the global capital 
markets. Upon sale of the MBS, lenders can turn around and make new loans 
using proceeds from the sale. In effect, the MBS is a way for the global capital 
markets to provide capital for loans to fund home ownership. The increased 
availability of capital reduces interest rates as compared to the interest rates 
that would otherwise be available, and therefore makes home ownership more 
affordable for an increased number of individuals. 

[0003] While the mortgage backed security approach has worked 
exceptionally well, home ownership rates could be further improved if loans 
could be used to create new forms of mortgage backed securities and/or other 
types of investment instruments or other assets that more optimally align with 
investor needs. A more optimal alignment would result in further increases in 
the availability of capital, further reductions in interest rates, and ultimately 
increased home ownership rates. 

[0004] Different investors typically have different investment needs. For 
example, different investors typically have different investment horizons. 
Thus, some investors may have short investment horizons and may be seeking 



WO 2004/061553 



PCT/US2003/036867 



one or more short term investment instruments, whereas other investors may 
have longer investment horizons and may be seeking one or more long term 
investment instruments. Different investors also typically have different risk 
criteria including different appetites for risk. For example, different investors 
may seek to avoid or accept different types risk depending on the types of risk 
already present in their investment portfolio. In the case of diversification, an 
investor may seek to diversify the investments it holds in order to avoid 
overexposure to any one type of risk. In the case of more sophisticated risk 
hedging strategies, an investor may consider itself to be overexposed to a 
particular type of risk, and may purchase investments that provide an effective 
hedge or counterbalance against that risk. Hedging is particularly useful for 
businesses that, by the nature of their business, may become exposed to 
certain types of risk. By purchasing investment instruments that are exposed 
to an opposing risk, a counterbalancing effect is achieved that promotes 
financial stability for the business. Most businesses engage in at least some 
form of risk management, and a business that effectively manages risk is more 
likely to survive in the long term for the benefit of its investors, its employees, 
and its customers. 

[0005] Therefore, the ability to provide investment instruments of varying 
investment horizons and risk characteristics is highly beneficial to investors. 
Even more beneficial would be the ability to more precisely parse risks and 
other characteristics from a pool of loans so as to create investment 
instruments that more precisely meet the needs of investors. To the extent this 
is achieved, homeownership rates and the economy as a whole are likely to 
benefit. 

[0006] In the global capital markets, various investment instruments have 
been created that provide investors with the ability to invest in instruments of 
varying investment horizons and risk characteristics. For example, in the 
context of the secondary mortgage market, real estate mortgage investment 
conduits (REMIC) instruments have been devised. The REMIC is a multiple- 
class mortgage cash flow security backed residential mortgage loans which 
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generally have been pooled together into MBS trusts. REMIC securities 
restructure interest and principal payments into separately traded securities. By 
redirecting the cash flow from the underlying standard MBS, the issue can 
create a security having several classes, also called tranches, which may carry 
different coupon rates, average lives, prepayment sensitivities and final 
maturities. Investors with different investment horizons have the opportunity to 
own a tranche that satisfies their investment criteria and portfolio needs. These 
tranches may be designed to emphasize or deemphasize the option risk of the 
underlying mortgage. Therefore, REMICs have provided a useful investment 
tool for some investors. 

[0007] REMICs, however, are limited in terms of the number of different 
types of investment instruments that can be created. REMICs are created 
based on MBS, and the typical MBS pooling process typically causes loan level 
cash flow data to be lost. Therefore, there typically are only so many ways to 
carve up an MBS to achieve investment instruments characterized by different 
risks, maturities, and so on. As a result, further improvements are needed. 

[0008] Often, in the creation of these financial assets, there are involved 
financial and/or tax accounting rules and/or practices that need to be addressed 
in transitioning from one type of financial asset to a different type of financial 
asset. The accounting rules can be internal rules or practices, established for 
improving the tracking and management of cash flows associated with the 
financial assets. Alternatively, these accounting rules can be rules or 
regulations established by regulatory agencies. 

[0009] Further, there is also a need for tools that accommodate and account 
for transactions in which cash flows from borrower payments that do not pass 
through straight to investors or other owners of loans assets, as in structured 
transactions. Such arrangements are often useful for providing adequate 
compensation to owners or other stakeholders in such loan assets or for other 
reasons. Even further, there is a need for a system that can be used to create 
cash flow aggregation structures and methods of making the same. Further 
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needed is such a system that can be tailored to comply with accounting rules 
or practices. 

[0010] A system or method that meets one or more of these needs would be 
highly desirable. It should also be understood that the techniques described 
and claimed herein may also be applied to meet other needs instead of or in 
addition to the above needs. For example, although the systems and methods 
discussed herein are described in terms of home mortgages, it will be apparent 
that the systems and methods to other types of assets, loans and/or other 
investments. 

SUMMARY OF THE INVENTION 

[0011] An exemplary embodiment is related to a financial asset embodied as 
a data construct in a data processing system. The data construct comprises 
description data, a cash flow map, and process instructions. The description 
data further comprises creation, purpose, and transaction information data 
describing the financial asset. The cash flow map further comprises 
information on cash flows that flow into the financial asset. The process 
instructions include information on cash flow processing for the cash flows 
that flow into the financial asset. 

[0012] Another exemplary embodiment is related to a packet that packages 
cash flows from financial instruments. The packet includes header data having 
creation, purpose, and transaction information; a data map including 
information on cash flows; and process instructions including information on 
cash flow processing. 

[0013] Another exemplary embodiment is related to a method of creating a 
packet. The method includes selecting assets, applying business rules to the 
selected assets, mapping cash flows associated with the selected assets, and 
applying packet creation rules to form at least one packet. 
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[0014] Another exemplary embodiment is related to a system that packages 
cash flows from financial instruments. The system includes means for 
selecting assets, means for applying business rules to the selected assets, 
means for mapping cash flows associated with the selected assets, and means 
for applying packet creation rules to form at least one packet. 

[0015] Other principle features and advantages of the invention will become 
apparent to those skilled in the art upon review of the following drawings, the 
detailed description, and the appended claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0016] The exemplary embodiments will hereafter be described with 
reference to the accompanying drawings, wherein like numerals denote like 
elements, and: 

[0017] FIG. 1 is a block diagram showing a cash flow engine in accordance 
with an exemplary embodiment; 

[0018] FIG. 2 is a flow chart showing cash flow decomposition in 
connection with the cash flow engine of FIG. 1 during a loan/asset 
configuration procedure; 

[0019] FIG. 3 is a block diagram showing cash flow decomposition in 
connection with the cash flow engine of FIG. 1; 

[0020] FIG. 4 is a flow chart showing cash flow decomposition in 
connection with the cash flow engine of FIG. 1 during loan/asset processing; 

[0021] FIGS. 5-7 are examples showing operation of the cash flow engine of 
FIG. 1; 

[0022] FIG. 8 is an example of a graphical user interface usable in 
connection with the cash flow engine of FIG. 1; 
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[0023] FIG. 9 is a diagrammatic representation of a packet in accordance 
with an exemplary embodiment; 

[0024] FIG. 10 is a diagrammatic representation of a flow diagram depicting 
exemplary a packet in accordance with another exemplary embodiment; 

[0025] FIG. 1 1 is a diagrammatic representation of packet contents in an 
exemplary packet; 

[0026] FIG. 1 2 is a flow diagram depicting exemplary operations in a method 
of creating packets; 

[0027] FIG. 13 is a diagram depicting exemplary packet creation operations 
and stages in a packet creation process in accordance with an exemplary 
embodiment; and 

[0028] Fig. 14 is a block diagram of a data processing system usable to 
implement the cash flow engine and packeting systems of FIGS. 1-13. 

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS 
I. Cash Flow Engine 

[0029] Referring now to FIGS. 1-2, FIG. 1 is a block diagram of a preferred 
cash flow engine 10 and FIG. is a flowchart showing operation of the cash 
flow engine 10 of FIG. 1 . Figure 1 shows an arrangement in which the cash 
flow engine 10 is used in connection with a plurality of loans 12 (individually 
labeled as Loan 1 through Loan M) and a plurality of financial assets 14 
(individually labeled as Financial Asset 1 through Financial Asset N). 

[0030] In the system of FIG. 1, each of the loans 1 2 is decomposed into a 
plurality of sub-loan level cash flows 15 (step 22, Fig. 2). The decomposition 
may be performed by a decomposition/repackaging tool 16, described in 
greater detail below, in response to user inputs during a loan set-up procedure, 
for example. The loans 12 may, for example, be home loans or other types of 
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loans. The cash flows 1 5 may be defined the same or differently for each of 
the loans 12. The cash flows 15 may include one or more positive cash flows 
associated with, fqr example, principal payments made by the borrower, 
interest payments made by the borrower, fees paid by the borrower, and so 
on. The cash flows 15 may also include one or more negative cash flows (or 
reductions in positive cash flows) associated with expenses or losses incurred 
with respect to particular loans, such as when a borrower defaults. Such 
losses/expenses are "negative" cash flows when considered from the 
perspective of the owner(s) of the financial assets backed by such cash flows. 
Preferably, the decomposition is performed such that substantially all sources 
of potential revenue/expenses for each of the plurality of loans is identified and 
associated with one of the cash flows 1 5. 

[0031] Referring now also to FIG. 3, exemplary cash flows according to one 
embodiment are shown. A cash flow may be source of payment, whether of 
principal, interest, or fees, received in connection with a loan. A cash flow may 
also be any type of expense incurred in connection with a loan. A given loan 
may produce positive cash flows associated with principal 30, interest 32, 
servicing fees 34, guarantee fee 36, mortgage insurance 38, prepayment 
penalties 40, borrower paid fees 42, servicer advances 44, and servicer 
recoveries 46, or negative cash flows associated with loss/default 48 and REO 
activity 50: 



Category 


Possible Cash Flows 


Principal 


Scheduled principal (amount payable based on 
scheduled amortization), actual principal (what 
was applied as principal), unscheduled principal 
(amount from borrower applied in excess of 
scheduled), advanced (amount not collected from 
borrower but remitted to investor), shortfall 
(underpayment from borrower, usually meaning 
less than full scheduled amount) 


Interest 


Scheduled Interest (amount payable), actual - 
(what was applied), excess (interest collection in 
excess of amount payable), advanced (not 
collected from borrower but sent to investor), 
shortfall (underpayment from servicer), capitalized 
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Category 


Possible Cash Flows 




(negative amortization), other capitalized interest 
(delinquency), unrecoverable prepayment interest 
shortfall 


Servicing 
Fees 


Gross servicing fee, core servicing fee (usually 
relates to tax), excess servicing fee, safe harbor 
(tax) 


Guarantee 
Fees 


Gross guarantee fee (GF) (total charged to the 
lender), cash flows for internally tracking costs 
(e.g., costs associated with credit risk), base GF, 
GF variance , and other GF adjustments 


Mortgage 
Insurance 


Lender paid mortgage insurance (Ml), borrower 
paid Ml, portion of GF construed to be Ml, 
back-end Ml 


Prepayment 
Penalties 


Prepayment penalty, prepayment penalty 
(borrower-paid), yield maintenance fee (borrower- 
paid). 


Borrower- 
paid fees 


Borrower-Paid Fees, late payment fee, 
conversion/modification fee. 


Seller 
advances 


Advanced principal, advanced interest, advanced 
guaranty fee, servicing advances (usually relates 
to defaults, e.g. T&l). 


Servicer 
recoveries 


Recovered principal advances, recovered interest 
advances, recovered guaranty fee advances, 
recovered servicing advances. 


Default 
activity 


Net realized loss (total amount payable to 
investors less all recoveries), foreclosure 
expenses, attorney fees, recoup of non- 
recoverable advances (detailed by type below), 
loss due to modification, loss due to appraisal 
reduction, loss due to deficiency valuation, non- 
capitalized deferred interest (e.g. workout), 
interest paid on advances. 


REO 
Activity 


Foreclosure sale proceeds, rental income, 
insurance proceeds, tax expenses on REO, repair 
expenses on REO, sale/marketing expenses on 
REO, REO property maintenance expenses. 



Table I: Possible Mortgage Cash Flows 



Herein, the term "cash flow" is used to refer generically to the source of 
payment (e.g., the right to receive borrower late fees) as well as the cash that 
flows from the source of payment (e.g., the cash paid by the borrower in the 
event that late fees are incurred). It may be noted that some of the above 
cash flows in Table I are aggregate cash flows that can be further 
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decomposed. Other cash flow pertinent information that may be tracked 
includes unpaid principal balance (UPB) (including scheduled UPB and actual 
UPB), participation percentage (including principal participation percentage, 
interest participation percentage, and servicing fee participation (basis points)), 
discount rate (used to calculate yield maintenance or prepayment penalty), 
appraised balance, foreclosure sale date, and REO sale date. Although Table I 
provides one example of cash flows that may be identified for a group of loans, 
it will be appreciated that other ways of parsing loans into a series of cash 
flows are also possible. Also, it may be desirable to establish a first set of 
cash flows for accounting purposes and a second set of cash flows for tax 
purposes. In general, cash flows may be decomposed in any manner desired 
including to any level of desired granularity. 

[0032] Additionally, it is also possible to aggregate cash flows from a 
borrower perspective or other entity perspective. For example, a series of loans 
(e.g., all to the same borrower) may be aggregated into a higher order cash 
flow and then the aggregation of the loans may be decomposed. Also, cash 
flows may further be derived from loans, pools, securities, commitments, and 
other packets. It is also possible to add cash flows to existing loans or other 
assets, for example, so that a new cash flow (e.g., for a new line of credit) 
may be established without having to set up a new loan. This latter feature 
provides additional flexibility to modify a borrower's loan over time. 

[0033] During the decomposition of the cash flows 15, information regarding 
the initial event that gave rise to the creation of cash flows 1 5 is preferably 
tracked and stored for accounting purposes. As detailed below, accounting 
rules are preferably applied to the financial assets 14 (e.g., packets) that are 
backed by the sub-loan level cash flows. Therefore, this information may be 
used to properly account for the event that gave rise to creation of the cash 
flow such that accounting rules and regulations can be satisfied. Additionally, 
the information may be used to determine the eligibility of cash flows 1 5 for 
inclusion in particular types of assets based on whether the accounting rules 
and regulations are satisfied. 
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[0034] Referring again to FIGS. 1-2, the decomposition/repackaging tool 16 
is then used to repackage the cash flows 1 5 into a plurality of financial assets 
14 backed by the cash flows 15 (step 24, Fig. 2). Herein, the term "financial 
asset" is used generically to refer to any asset that is backed by one or more 
cash flows, and includes such things as assets that are created entirely for 
internal data tracking purposes (e.g., in the case of packets which do not 
represent securities), as well as assets that have external significance (e.g., in 
the case of MBS or other financial instruments). The financial assets 14 may 
each backed by one or a combination of the cash flows identified above. It 
may be noted that the financial instruments 14 are preferably created such that 
the collateral for the financial instruments 14 is the plurality of sub-loan level 
cash flows 1 5 and not the plurality of loans 1 2. Also, it is not necessary to 
securitize the loans 1 2 and then create financial instruments by performing 
strips of the security; the financial instruments may be backed directly by the 
cash flows 1 5. Such financial assets 14 may be held in the portfolio of, for 
example, the owner/operator of the cash flow engine 10, or may be sold to a 
third party investor. 

[0035] It is possible to use the cash flow engine 10 to create a variety of 
financial instruments backed by the loan level cash flows 15, which is 
particularly useful in a situation where the financial asset 14 is a financial 
instrument configured for sale to a third party investor. As previously 
indicated, in the past, loans have been pooled to form MBS. The cash flow 
engine 10 is capable of creating such MBS, as well as other types of financial 
instruments. The financial instruments may be pass through type instruments 
such as MBS, or structured instruments such as debt instruments 
(subordinated debt, unsecured corporate debt, callable debt securities, bonds, 
etc.), options, swaps, insurance policies, or other instruments where the 
connection of the asset to the cash flow is less direct than in a pass through 
instrument. Any combination of one or more cash flows may be selected to 
create a financial asset. Preferably, such "cash flows are aggregated with like 
cash flows from other loans in creating the financial asset. For example, a 
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financial instrument may be created that is backed only by one or more specific 
types of borrower paid fees, and not by principal and interest. The financial 
instruments may be constructed so as to accentuate or deaccentuate specific 
types of risk (e.g., credit risk). The financial instruments may have different 
risks/payment profiles depending on which of the cash flows shown in Table I 
backs the financial instrument. Such financial instruments may be used to 
transfer interest rate risk, credit risk, and other types of risk to third party 
investors, and provide the third party investors with the opportunity to pursue 
more aggressive risk profiles and thereby greater potential yields. 

[0036] For example, the cash flow engine 10 may be us^d to issue non- 
guaranteed corporate debt backed by one or more of the cash flows 15. 
Therefore, for example, it is possible to create financial instruments that 
transfer risk in the form of debt to a third party investor, and reward the third 
party investor for taking on such risk. Thus, for example, a debt instrument 
may be constructed in which the investor is paid with cash flows derived from 
principal payments in connection with a group of loans, but a credit loss trigger 
may be included in which the investor is no longer paid if credit losses exceed 
a certain level. Such an arrangement is advantageous for the investor because 
the investor is rewarded for assuming the credit risk associated with the loans. 
The trigger events used in constructing such debt instruments may be directly 
related to the group of loans or may be related to some other event. 

[0037] As another example, financial instruments may be created that are 
based on special loan programs. For example, for borrowers having marginal 
credit, a loan program may reward such borrowers with a reduced interest rate 
after such borrowers have made a certain number loan payments in a timely 
manner (e.g., a reduction from 7.5% to 6.5%). The potential that the 
borrower will make timely payments and reduce the cash flows associated 
with their loan represents a risk that may be sold to a third party investor. For 
example, for a group of loans consisting of such loans, a first financial 
instrument may be created that is backed by the underlying 6.5% interest rate, 
and a second financial instrument may be created that is backed by the 
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additional 1 % portion of the interest rate that is subject to elimination after the 
loan payments are made in a timely manner. The first financial instrument 
therefore would be relatively insensitive to the risk associated with the reward 
program, whereas the second financial instrument would have an enhanced 
sensitivity to such risk. Depending on the portfolio needs of a particular 
investor, the second financial instrument may fit within the investor's portfolio, 
for example, by serving as a hedge against other risks. 

[0038] Many different risk transfer mechanisms may be created using one or 
more of the different possible cash flow identified in Table I. The cash flows 
can be decomposed to any desired level of granularity. Due to the high level of 
granularity of the cash flows can be identified (e.g., as in Table I), and due to 
the fact that different cash flows represent different types of risk, it is possible 
to parse out risks from loans with a high degree of precision, and transfer 
those risks to investors with specific investment needs. 

[0039] The cash flow engine 10 may also be used to create financial 
instruments that serve other purposes other than transferring risk. Thus, as 
yet another example, when a lender sells a loan to a secondary market 
participant, oftentimes, the lender will retain a portion of the interest as a 
servicing fee. In some instances, the servicing fee that is charged to a 
borrower is in excess of the amount that the Internal Revenue Service 
considers to be a core servicing fee. The core servicing fee is the portion of 
the servicing fee charged to the borrower that the lender can retain as 
compensation and still have the sale of the loan be considered a "sale" for tax 
purposes. Therefore, in order to receive favorable tax treatment for the sale of 
the loan, lenders typically will retain only the core servicing fee, and the excess 
servicing fee (the remainder of the servicing fee charged to the borrower) is 
sold to the purchaser. In some instances, it may be desirable to create a 
financial instrument that is backed by the excess servicing fee in order to 
optimize the value that is received for this fee. 
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[0040] As yet another example, financial instruments may be created that 
correct certain anomalies that may exist in certain situations. For example, 
with regard to servicing fees, there is a mismatch between the manner in 
which servicers are paid and the servicers' cost structure. Servicers typically 
retain a portion of the interest that is paid by a borrower each month as 
compensation for performing the servicing function. Because the interest 
portion of a borrower's monthly payment decreases each month as equity 
increases, the servicer's compensation also decreases incrementally each 
month. However, the cost of servicing loans does not decrease each month, 
particularly when costs associated with defaulted loans are taken into account. 
Therefore, it is possible to repackage the cash flows from the underlying loans 
to create a payment structure for the servicer that is more closely aligned with 
the servicers' cost structure. 

[0041] In order to assist with the generation of such financial instruments 
and other assets, the cash flow engine 10 may also be coupled to financial 
engineering tools 18 (step 26, Fig. 2), which are tools usable by an operator to 
analyze, design, develop, and/or implement the financial assets 14 and/or 
related processes. For example, the financial engineering tools 1 8 may be 
computer-implemented tools usable for analyzing financial data, assessing and 
predicting financial performance, valuing financial assets, analyzing financial 
risk, and so on, regarding the loans 1 2, the financial assets 14 and/or the cash 
flows 15. To this end, the financial engineering tools 18 preferably include 
tools responsive to operator inputs for creating and displaying interactive 
graphs and other visual representations of financial data using mathematical 
models and simulations. Such models and simulations may be constructed 
using the financial engineering tools 1 8 and may take into account market 
conditions, contract terms, and other factors, with different models being 
available for different financial instruments to allow the model that best 
represents market dynamics and other factors such as contract terms to be 
selected. 
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[0042] Additionally, certain accounting rules may apply that may affect the 
manner in which cash flows may be most optimally stripped and the manner in 
which financial assets may be most optimally created. In the above example, 
where it is desirable to create a financial asset based on the servicing fees for 
a loan or a collection of loans, accounting rules may apply that state that the 
servicing fees cash flow is an interest strip and must be accounted for as an 
interest only strip. An interest only strip is a type of strip that subjects the 
cash flow to derivative accounting, meaning that a lender must recognize gains 
or losses when the market value of the underlying asset increases or decreases 
in value. Therefore, the financial engineering tools 18 preferably include tools 
usable to assess financial risk, predict financial performance, and so on, of 
financial assets in view of such accounting rules. 

[0043] Referring now also to FIG. 4, after the financial assets 14 are created 
using the decomposition/repackaging tool 1 6, payments in connection with the 
financial assets 14 are funded by the cash flows from the loans 1 2. For 
example, in the case of an investment instrument that has been sold to a third 
party investor, the cash flows may be used to fund payments to the investor 
(either on a straight pass through basis or on a structured basis, depending on 
the type of financial instrument created). 

[0044] The cash flow engine 10 includes accounting/reporting tools 17 
which receives payment information regarding incoming cash flows associated 
with the loans 1 2 (step 52). The payment information may be received from a 
computer system that supports loan servicing. The payment information may, 
for example, include information regarding scheduled principal payments made 
by the borrower, unscheduled principal payments made by the borrower, 
interest payments made by the borrower, fees paid by the borrower, and so 
on. The borrower payments are then decomposed into the various defined 
cash flows (step 54). If the computer system that performs loan servicing 
supports such reporting, the payment information may be received in a more 
granular form and include information regarding each of the cash flows 
processed by the cash flow engine 10. Otherwise, the information regarding 
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such cash flows may be computed by the cash flow engine 1 0 based on the 
information reported by the servicing computer system. The payment 
information is then processed in accordance with stored mapping information 
regarding the manner in which cash flows flowing into the financial assets 14 
are traceable back to the cash flows 15. Thus, after the mapping information is 
accessed, portions of the loan payments corresponding to the level cash flows 
1 5 for each of the loans 1 2 are repackaged and allocated to a respective one 
of the financial assets 14 based on the mapping information (step 54). As a 
result, information regarding investment proceeds due to the owner(s) of the 
financial assets 14 is generated, and the owner(s) of the financial assets 14 
may be paid with funds derived from the loan payments and in accordance 
with the repackaging of the cash flows 1 5 to the respective ones of the 
financial assets 14 (step 56). 

[0045] According to an exemplary embodiment, the accounting/reporting 
tools 17 apply accounting rules directly to the financial assets 14, even though 
many of the financial assets 14 are not necessarily loans or securities. As has 
been described, the financial assets 14 are created by repackaging the cash 
flows 15. The accounting treatment that is given to each financial asset 14 
depends on the nature of the cash flows 1 5 which back the particular financial 
asset. For example, if a plurality of cash flows 15 derived from borrowers in 
connection with a corresponding plurality of different loans is repackaged to 
form one of the financial assets 1 4, and the nature of the cash flows requires 
interest-only accounting, then that financial asset 1 4 may be accounted for as 
an interest only strip. Thus, for each of the financial assets 14, the nature of 
the cash flows that are repackaged to form the financial asset 1 4 is analyzed 
to determine the proper accounting treatment for the financial asset 1 4. After 
the appropriate accounting treatment is determined (typically during steps (22- 
26), accounting calculations may be performed during the life of the financial 
asset in accordance with the determined appropriate accounting treatment. To 
this end, the accounting/reporting tools 1 7 therefore preferably includes tools 
for performing typical accounting calculations such as present value, 
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depreciation, and so on. Additionally, the payment information received by 
accounting/reporting tools 1 7 includes information pertinent to accounting such 
as information concerning the origin and timing of the payments or other cash 
flows and other relevant information. 

[0046] Thus, the cash flow engine 10 permits the financial engineering tools 
1 8 to be used in connection with the purchasing and repackaging of loan 
assets into financial instruments. Particularly, each of the loans 12 has 
associated with it a number of different cash flows which are parsed and 
reconfigured into a variety of different financial instruments 14. The cash flow 
engine 10 decomposes each loan into its constituent parts and allows financial 
engineering tools 1 8 to be applied at the loan level rather than only at the pool 
level. Additionally, the cash flow engine 10 is able to process cash flow 
information at a much higher level of granularity than has been possible in the 
past. For example, not only is the cash flow engine 10 able to track interest 
payments from each loan, but the interest payments may be subdivided into 
constituent cash flows such as servicing fees, G-fees, and pass through 
interest. The cash flow engine 10 also recognizes the existence of other types 
of cash flows which have not traditionally been viewed as cash flows that 
could accrue to an investor (e.g., late fees, prepayment penalty fees, and so 
on). The cash flow engine 10 is also recognizes the existence of negative cash 
flows (e.g., in situations where a borrower defaults on the loan). 

[0047] These features provide greater flexibility in creating financial 
instruments and allow more optimal financial instruments to be created. In 
particular, financial instruments may be created that are more optimally aligned 
with what the purchaser wishes to purchase. 

[0048] The cash flow engine 10 also provides benefits even in situations 
where the financial instruments 14 are not sold to external investors. For 
example, a holder of loan assets may use the cash flow engine 10 and the 
financial engineering tools 1 8 to examine loan assets at a high level of 
specificity and granularity. The cash flow engine 10 provides the ability to 
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more precisely track risks, monitor performance, and perform other detailed 
analysis in connection with various aspects of the plurality of loans 12. This 
allows the investor to obtain a better understanding of how the loan assets 
performed which would in turn would allow the investor to make better 
decisions about which assets to buy in the future. 

[0049] Additionally, the high level of data granularity allows more accounting 
information to be associated with each of the cash flows 15. This accounting 
information aids in compliance with accounting rules and regulations. The 
information further aids the user in tracking cash flows for internal accounting 
to optimize analysis of processes and cash flows. 

[0050] Referring now to FIG. 5, an example of a cash flow 
decomposition/repackaging operation that may be performed by the cash flow 
engine 10 is illustrated. Although the cash flow repackaging operation is 
shown in connection with one of the loans 1 2 shown in FIG. 1 , it will be 
appreciated that similar operations are also performed with respect to other 
ones of the loans 1 2 shown in FIG. 1 . 

[0051] Figure 5 is divided into three rows. The first row, labeled "financial 
asset," illustrates the financial asset (e.g., loan, packet, etc.) that is the source 
of the cash flows under consideration. The second row, labeled "cash flow 
allocation summary," illustrates cash flows that are available from the financial 
asset contained in the first row. Preferably, the cash flow engine 10 stores the 
information embodied in the second row in the form of a cash flow allocation 
summary ("CFAS") map. The CFAS map represents the manner in which loans 
are decomposed into cash flows. The third row, labeled "packet cash flow 
allocation/' illustrates how the cash flows identified in the second row are 
used by packets. As described in greater detail below in connection with FIGS. 
8-1 1, a "packet" is an aggregation or packaging of cash flows that is treated 
as an entity separate and distinct from the incoming cash flows that support it 
and from the cash flows that result from it. A packet is an example of a 
financial asset used for internal mapping and data tracking. As in the case of 
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the CFAS map, preferably, the cash flow engine 10 stores the information 
embodied in the third row in the form of a packet cash flow allocation 
("PCFA") map which shows the cash flows that flow into packets. 

[0052] In the example of FIG. 5, the loan 1 2 has a scheduled principal cash 
flow 62, an unscheduled principal cash flow 64, an LPT (or lender pass 
through portion of the interest rate) cash flow 66, and a guarantee fee ("G- 
f ee ") cas h flow 68. The scheduled principal cash flow 62, the unscheduled 
principal cash flow 64, and the G-fee cash flow 68 are represented as being 
unallocated. The LPT cash flow 66, shown to be 6.5% adjustable rate 
interest, is represented as being 100% allocated between a residual cash flow 
70 and an IPT (or investor pass through portion of the interest rate) cash flow 
72. The portion of the cash flow 66 which is allocated to the IPT cash flow 
72 is 300 bps fixed rate interest; the remainder is allocated to the residual cash 
flow 70. The IPT cash flow 72 is 100% allocated to a packet 74. The packet 
74 may then be used to back a financial instrument, or may be further 
decomposed in generally the same manner that the cash flow 66 is 
decomposed. In other words, the decomposition/repackaging may be 
performed both regard to the loan 1 2 and other financial assets 14 to create 
multiple layers of cash flow decomposition/repackaging. It is thus seen that 
complete flexibility is achieved in the manner in which cash flows may be 
decomposed and repackaged to form financial instruments or other financial 
assets. 

[0053] Referring now to FIG. 6, another example of a cash flow 
decomposition/repackaging operation that may be performed by the cash flow 
engine 10 is illustrated. In the example of FIG. 6, the loan 12 has a scheduled 
principal cash flow 82, an unscheduled principal cash flow 84, an LPT cash 
flow 86, and a gross servicing fee cash flow 88. The cash flows 82-86 are 
unallocated. The gross servicing fee cash flow 88 is, shown to be 0.35% 
fixed rate, is represented as being 100% allocated between a fixed ($50) 
servicing fee cash flow 90 and a residual cash flow 92. The fixed servicing fee 
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cash flow 92 is 100% allocated to a packet 94. The packet 94 is a financial 
asset in the form of a fixed ($50/month) servicing fee. 

[0054] Thus, the arrangement of FIG. 6 may be used to address the above- 
mentioned problem regarding compensation structures for servicers. 
Specifically, in conventional mortgage products, the loan asset comprises a 
right to receive loan payments (including a principal payment portion and an 
interest payment portion) from a borrower in connection with the loan. The 
servicing asset comprises a right to receive a servicing fee portion of the 
interest payment portion in exchange for performing servicing of the loan. 
However, as the unpaid principal balance of the loan decreases, the servicing 
fee portion of each loan payment also decreases, even though the costs of 
servicing loans typically increases on average further into the term of the loan. 

[0055] Pursuant to the arrangement of FIG. 6, a secondary market 
participant (e.g., an investor in loans) may acquire a home mortgage loan 1 2 
having a loan asset and a servicing asset. The secondary market participant 
then repackages the cash flows associated with the loans to create a modified 
servicing fee (packet 94) which provides a different compensation structure for 
the servicer than the servicing fee portion of the loan payment. The secondary 

market participant then subcontracts responsibility for performing servicing of 

i 

the loan to a servicer and compensates the servicer with the modified servicing 
fee. Alternatively, rather than subcontracting servicing, the secondary market 
participant could also resell the servicing asset to the servicer in a modified 
form in which the servicing asset permits the servicer to retain the modified 
servicing fee. Either way, the servicer performs servicing of the loan during 
the term of the loan and receives the modified servicing fee as compensation. 
As illustrated, the compensation provided to the servicer does not decrease 
through time during the term of the loan, but rather is fixed (e.g., a $50 
monthly payment). Alternatively, the modified servicing fee may be 
constructed so as to increase during the term of the loan. In practice, given 
that it is the servicer that receives loan payments from the borrower, 
compensating the servicer may simply comprise permitting the servicer to 
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retain its compensation from payments received by the servicer from a 
borrower before the payments are aggregated and forwarded to the secondary 
market participant. Thus, the arrangement of FIG. 6 produces a payment 
structure that is more closely aligned with the servicers' cost structure, 
addressing the servicer cost structure problem previously described. 

[0056] It may also be noted that, over time, when the gross servicing fee 
cash flow 88 portion of the loan payment becomes less than $50 due to 
increased equity, the residual cash flow 92 will become a negative cash flow. 
The negative cash flow operates to reduce other positive cash flows (not 
shown) in an amount necessary to provide the servicer with a fixed $50/month 
servicing fee even though interest payments on the loan are decreasing. 
Notably, therefore, the system 10 is capable of tracking negative cash flows. 

[0057] Preferably, in this arrangement, additional accounting information is 
tracked to properly account for the underlying assets. For example, the value 
of the gross servicing fee cash flow 88 portion of the loan payment may need 
to be related to the value of the loan 12 from which it originates to properly 
satisfy accounting rules. Accordingly, this information may be analyzed and 
tracked by the accounting/reporting tools 17 to facilitate accounting. 

[0058] Referring now to FIG. 7, another example of a cash flow repackaging 
operation that may be performed by the cash flow engine 10 is illustrated. In 
the example of FIG. 7, the loan 12 has a scheduled principal cash flow 102, an 
unscheduled principal cash flow 104, a LPT cash flow 106, and a G-fee cash 
flow 108. The cash flows 102 and 104 are 100% allocated to a packet 1 14. 
The cash flow 106 is unallocated. The cash flow 108 is 100% allocated to a 
residual cash flow 1 10 and a IPT cash flow 1 12, which is 100% allocated to 
the packet 1 14. The packet 1 14 may receive similar cash flows from other 
ones of the loans 1 2. The packet 1 14 is decomposed to produce a scheduled 
principal cash flow 122, an unscheduled principal cash flow 124 and a IPT 
cash flow 126, each of which is shown as being unallocated. 
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[0059] Figures 5-7 represent both the manner in which decomposition and 
repackaging occur during loan/asset set up and the manner in which 
decomposition and repackaging occur during loan/asset data processing during 
the life of the loans 12. In connection with loan/asset data processing during 
the life of the loans 1 2, it may be noted that FIGS. 5-7 present a static view of 
data processing and particularly the way in which cash flows flow from the 
loans 1 2 to the assets 14. Of course/there is also a dynamic (time-based) 
aspect loan/asset data processing due to the fact that borrower payments may 
be received on different days, servicers have different deadlines for reporting 
data, and so on. Therefore, cash flows may flow into certain ones of the 
financial assets (packets) 1 4 on certain days and flow into other ones of the 
packets assets (packets) 14 on different days. Preferably, and as described in 
greater detail below in connection with FIGS. 8-1 1, the packets are created so 
as to include process instructions that take such time-based elements into 
account. 

[0060] Referring now to FIG. 8, in order to perform cash flow decomposition 
and repackaging during loan/asset set up, a graphical user interface (GUI) may 
be used that displays decomposition and repackaging information to a user and 
receives operator inputs used in creating/modifying relationships between 
loans, cash flows, and assets. Such a GUI may comprise an operator input 
interface (e.g., program logic) that receive operator inputs using a suitable 
input devices (e.g., keyboard, mouse, and so on) and a display interface (e.g., 
program logic) that drives an output device (e.g., computer display) to display 
indicia regarding the loans 12, the assets 14 and the cash flows 15 in tabular, 
iconic, block diagram, or other formats. 

[0061] For example, in one embodiment, the graphical user interface is 
organized in a manner generally similar to FIGS. 5-7. Thus, FIG. 8 is the same 
as FIG. 7, except that reference numbers have been changed such that a 
description of an exemplary GUI 1 50 may be given. The GUI 1 50 comprises a 
display interface which displays indicia (icon 152) representative a home 
mortgage loan 12, indicia (e.g., icons 154) representative of the cash flows 
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15, indicia (e.g., icons 1 56) representative of the plurality of financial assets 
14, and indicia (e.g., lines 158 extending between the icons 152-156) 
representative of a manner in which cash flows that flow into the financial 
assets 14 are traceable back to one or more of the plurality of home mortgage 
loans 1 2. Other information may also be displayed. For example, in the 
illustrated embodiment, information regarding an extent to which individual 
ones of the cash flows 15 have been allocated (e.g., "100% used") to the 
financial assets 14. Additionally, the icons 152-156 may also be displayed in a 
manner (e.g., different colors, different symbology, and so on) that provides 
additional information regarding the type of loan, cash flow, or asset that the 
icon is intended to represent. 

[0062] As numerous decomposition/repackaging operations are performed 
for multiple loans and multiple financial assets, different icons are displayed 
that represent the different loans, the different cash flows, and the different 
assets. Such information may be either displayed simultaneously or at 
different times on different display screens, depending on how much 
information it is considered desirable to provide operator with at once. The 
operator input interface then receives operator inputs which define the manner 
in which each of the loan 1 2 are to be decomposed into the cash flows 1 5 and 
the manner in which the cash flows 15 are to be repackaged to form the 
financial assets 1 4. For example, the operator interface may receive inputs 
identifying specific loans for decomposition, cash flows that are to be 
decomposed, the allocation of the cash flows from one or more loans to one or 
more specific assets, the allocation of cash flows between assets, and so on. 
The operator inputs may also be used in connection with sifting logic and 
sorting logic. As will be described in below, sifting logic is provides a 
mechanism by which users can examine the entire collateral universe and pair 
down to smaller groupings of collateral or assets within the universe, and 
sorting logic provides a mechanism by which user may group the subset of 
collateral identified in the sifting process and organize it by a single or multiple 
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attributes to further refine the pool of candidate collateral to be placed into a 
potential packet. 

II. Packet System 

[0063] Referring now to FIGS. 9-13, exemplary embodiments of a packet 
system and related methods will now be described. These exemplary 
embodiments describe the creation, maintenance, and dissolution of cash flow 
aggregation structures, or "packets/' Such a structure includes a mapping of 
asset cash flows to a higher order and the effective dates for those mappings. 
The cash flow aggregation structures and methods can be implemented in a 
wide variety of different ways. Various embodiments may include, for 
example, packets with other types of attributes or packets formed in other 
ways than those described. 

[0064] In the preferred system of FIGS. 9-13, a packet is an aggregation or 
packaging of cash flows that is treated as an entity separate and distinct from 
the incoming cash flows that support it and from the cash flows that result 
from it. The packet can be used for both the collection and distribution of data 
and monies. Although, exemplary embodiments described herein use the term 
"packet" to refer to the distribution or re-distribution of cash flows after their 
collection, the interpretation of "packet" should not be limited by the examples 
provided. 

[0065] Packets provide data integrity of underlying reported assets and 
create an information chain that maps to a higher-order form of recognized 
asset. The source data for packets may be loan-level or packet-level 
information, and the packets themselves may represent actual securities or just 
a unit of reporting and remittance. 

[0066] Besides capturing the relationship between sources of cash flow and 
the packaging thereof, a packet also tracks certain descriptive data about 
itself. For example, a packet has information about its own attributes, the 
disposition of its cash flows, and any reported output, including disclosure 
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data. Additionally, a packet describes its process behavior, which may be 
derived from external business rules. These business rules may be standard 
(as would be the case for mortgage-backed security packets), or they may 
apply to a specific packet (as might happen in a structured transaction). 
Sources of incoming cash flows to a packet may be loan remittances, 
percentages of loan remittances, pool distributions, percentages of pool 
distributions, securities, or other types of synthetic or real assets. 

[0067] Packets provide a data map that permits inspection of loan assets 
and securities assets when data exists at both levels. The ability to create and 
manipulate packets enables the creation of new types of financial products. 
Packets also improve the processing of transactions and support of new types 
of transactions within the secondary market. 

[0068] By way of example, FIG. 9 illustrates a packet 210 including a 
packaging of cash flows. The packet 210 can include packet type information 
214, packet state information 218, asset information 222, asset type 
information 226, information 230 regarding allocation of cash flows from 
asset, and effective date information 234. 

[0069] The packet type information 21 4 indicates the type of financial asset 
associated with the packet, for example, the packet 210 may be associated 
with an OOP (out of portfolio) pool, MBS pool, lender-formed MBS pools, 
Mega, Choice pools, Majors, Pseudo pool, Reference pool, excess servicing 
strip, excess/deficit yield, stripped loan, or other type of structure. The packet 
type information 214 may also describe, for example, who is expected to 
initiate the creation of this packet type, how the packet to be created, 
attributes required for creation of the packet, minimum set of disclosure data, 
packet statistics, estimated frequency of creation, rules for dissolving the 
packet if the packet is in production, necessary accounting events, and 
system(s) responsible for performing roll-up of the packet. The packet type 
helps determine which business rules to apply. The packet type further enables 
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the accounting/reporting tools 18 to make a determination as to which 
accounting rules to apply. 

[0070] The packet state information 218 indicates whether, for example, the 
packet is at a pre-packet, pending packet, or production packet stage. The 
asset information 222 indicates a set of assets, such as, loan #1 interest, loan 
#1 principal, loan #2 principal, etc. The asset type information 226 indicates 
the underlying asset type, e.g., loan, MBS, etc. The information 230 regarding 
allocation of cash flows from asset indicates, for example, the money amount, 
percentage allocation, or basis point amount of the cash flow. The effective 
date information 234 indicates the effective dates for the participation of each 
cash flow in the packet. 

[0071] Although several specific attributes are described as composing 
packet 210, additional, fewer or different attributes may be used for packet 
creation. Examples of additional attributes can include: applicable business 
rules, alternate exception flow, additional reporting/disclosure requirements, 
additional accounting components, ticker symbol, and conduit tagging 
specification for underlying cash flows and/or assets. 

[0072] By way of another example, FIG. 10 illustrates a packet 236 
including a header 240, a map 242, process instructions 244, and output 
requirements 246. The header 240 includes packet header data, such as, 
creation, purpose, and transaction information. More specifically, packet 
header data in the header 240 can include packet ID (unique), packet type, 
packet state, date of when packet was created, time of when packet was 
created, user/System ID of creator of packet, and an indicator of whether the 
packet represents a security or is merely a reporting entity. 

[0073] The map 242 includes information on cash flow and disclosure issues 
such as, an identifier, a cash flow quantity, a disclosure basis quantity, and a 
date in. Two exemplary ways in which the map 242 for a packet can be 
formed are GUI (graphical user interface)-based mapping and GUI-less mapping. 
The GUI-based mapping occurs when a user accesses a sift/sort. screen to 
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identify collateral. Once the collateral assets have been identified, the next 
step is to bring up a packet detail mapping GUI in which the user can select 
the specific sources of cash flow and quantities thereof to be added to the 
designated packet. These functions may be included as functions that may be 
performed by the GUI 150, described above. 

[0074] The GUI-less mapping occurs when all the required elements of a 
packet are present. Accordingly, no GUI is needed to build the detailed packet 
map. In such scenario, a template by transaction type is used to set the 
default values in the resulting packet. This concept is described below. 

[0075] A ''transaction type" describes what type of business event is 
occurring, most often, but not always, indicating what type of security is being 
created. Transaction types can include MBS, ABS, REMIC, Whole Loan 
REMIC, Excess Servicing Strip, Grantor Trust, Structured Transaction 
(undifferentiated), Credit-Linked Note, SMBS (stripped MBS), Whole Loan Sale, 
or Loan Strip. 

[0Q76] The GUI for packet detail mapping contains a list of possible sources 
of cash flow, and allows users to designate the quantity of each to be 
packetized. The possible sources of cash flow are derived from the nature of 
the underlying asset(s). If the collateral asset is another packet, only those 
cash flows that are included in the collateral packet (and therefore available for 
re-packeting) are displayed. If the asset is a mortgage loan, then loan-level 
cash flows are displayed. If possible, the screen derives which cash flows are 
available at the loan level based on what is (or will be) reported by the servicer. 
It is also possible that certain types of cash flows may be deemed unavailable 
for inclusion in the packet based on the accounting or business rules that are 
applicable to the cash flows. 

[0077] In addition to selecting the cash flows to be placed in the packet, 
users can select the quantity to be packetized. Packet detail mapping 
templates are performed for different types of packets, based on transaction 
type. These templates store defaults for the cash flow elements and their 
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quantities values. For example: if the packet type is "MBS Pool," the template 
automatically defaults the quantities of SCHEDULED UPB (unpaid balance) to 
100%, SCHEDULED PRINCIPAL to 100%, UNSCHEDULED PRINCIPAL to 
100%, and SCHEDULED INTEREST to the logical value given the target pass- 
thru rate of the MBS. If the transaction type is "Whole Loan REMIC" or 
"Excess Servicing Fee Strip," different templates with different default values 
are called. 

[0078] In addition to mapping cash flow elements, the transaction type 
default template has a list of default disclosure reports. If an individual request 
to create a packet does not specify disclosure report types, this service assigns 
the disclosure reports for a given packet based on the defaults for the specified 
transaction type. The disclosure reports preferably include information to 
facilitate accounting for the packet to be created based on the accounting 
information received for the cash flows incorporated in the packet. For 
example, where the cash flow is considered a derivative cash flow, the 
accounting value of the packet may be determined based upon the value of the 
underlying asset from which the cash flow originates. 

[0079] The GUI for mapping the data gives users the ability to map cash 
flows and quantities identically for all assets, for selected groups of assets, or 
one-by-one for individual assets. This GUI also allows users toispecify 
quantities in a variety of formats: as specified values, as percentages, in basis 
points (bps) (for interest-related cash flow sources only), or as a formula. An 
example of the latter would be in an excess servicing fee strip, where the 
quantity of servicing fee to be packeted could be expressed as "all SF > 25 
bps at the loan level." Results of this GUI will be used to form the PACKET 
DATA USE MAP that completes the packet definition in the illustrated 
embodiment. 

[0080] The process instructions 244 include information on cash flow 
processing, such as, roll-up frequency, payment and payoff activity cutoff, roll- 
up business rules, and applicable accounting rules. The output requirements 
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246 include information on cash flow output, such as, output reporting, 
accounting reporting, release date, and public or private status. Additional 
information can be included in the packet 236. 

[0081] FIGURE 1 1 illustrates packets 250 and 252 having exemplary packet 
content. The packet 250 is a MBS packet including a header 254, an optional 
header 256, a data use map 258, periodic process data 260, and output 262. 
The packet 252 is a Mega packet including a header 266, an optional header 
268, a data use map 270, periodic process data 272, and output 274. 

[0082] FIGURE 1 2 illustrates a flow diagram 280 of an exemplary method of 
creating packets. Whether creating a packet with or without a GUI, the 
process of creating a packet can include a step 282 in which assets are 
selected by a sift and sort process. In an exemplary sift process, assets are 
examined for selected attributes and the assets are grouped based on the 
selected attributes. For example, loans can be searched for 30 year fixed rate 
mortgages in New York. In an exemplary sort process, the results from the 
sort are prioritized. In the mortgage example given, the results could be 
prioritized based on length of term remaining. 

[0083] After operation 282, a step 284 is performed in which loan/asset 
eligibility business rules are applied. Such rules provide a set of filters that 
override user-defined characteristics used in the sift and sort process. For 
example, a business rule may be that no more than 10% of loans can be 
relocation loans. Such a rule would place a limit on loan assets collected in the 
packet creation process. 

[0084] In a step 286, detailed cash flows are mapped and in a step 288 
packet creation business rules are applied. These results can be persisted in a 
database and the accounting and disclosure operations applied. The user can 
append or relax certain business rules specific to a deal, based on Deal ID. 

[0085] Non-portfolio packet cash flows and assets can be analyzed with 
standard edits for completeness. Selected cash flows and assets are checked 
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to ensure that they are not being used by another packet. Cash flows and 
assets may be reviewed under the edits and eligibility rules for packetization 
(specific rules vary according to packet type and may be specific to a single 
packet). Selected cash flows and assets may be selected that are in 
''production. " Cash flows and assets may pass any additional business rules 
not covered by the eligibility rules. The cash flows that pass the rules are 
eligible to "belong" to the packet. Status of underlying cash flows and assets 
may then be appropriately updated based on packet state. Allocations of 
available cash flows may also be appropriately updated to reflect portions of 
cash flows.no longer available. Accounting treatments of underlying cash 
flows and assets may also be updated, if necessary. Proper book and tax 
accounting for production packets may also occur. Appropriate disclosure 
reports may also be generated. Statistics for the packet may also be 
calculated (roll-up). 

[0086] In certain situations, packets may need to be modified such as 
another user requiring a cash flow that is already in a pre-packet. Types of 
modifications to packets include removal of underlying cash flows, substitution 
of cash flows, and addition of cash flows. When a packet is modified, it goes 
through a subset of the steps required for packet creation. Production packets 
can require additional reporting, logging, and accounting steps. 

[0087] Different types of updates can be applied to packets at different 
states. For example, modifications to selected assets made before the packet 
detailed map is created are local updates. Modifications made after the packet 
detailed map is created but while the packet is still in "pending" status are 
most likely to be triggered as a result of lender activity. Users may add, 
remove or substitute loans and/or cash flows in a pending packet. 
Modifications made to a production packet can be triggered by an attribute 
change processor (which, in the illustrated embodiment, is part of the system 
described below in connection with FIG. 13). Events such as BuyUp/BuyDown, 
Dissolves, and Loan Substitutions can trigger a packet modification event. 
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[0088] If a cash flow is added, removed or substituted (in essence, 
removed), the following actions happen on that cash flow. First, the status of 
underlying cash flows and assets is appropriately updated based on packet 
state. Conduit codes of underlying cash flows and assets are updated, if 
necessary. The cash flow link to the packet is removed. 

[0089] Following the cash flow updates, the following events occur on the 
newly formed packet. First, added cash flows and assets pass standard edits 
for completeness. Next, the packet's cash flows and assets are checked to 
ensure that they are still eligible for packetization (e.g., another packet has not 
used them). Cash flows and assets pass the edits and eligibility rules for 
packetization (specific rules vary according to packet type). 

[0090] As previously noted, accounting/reporting tools 17 apply applicable 
accounting rules to the packets to determine accounting reporting and actions. 
The origin and nature of the underlying cash flows are included in information 
associated with the packet to facilitate application of the accounting rules. 

[0091] Cash flows and assets can be reviewed to ascertain whether they 
pass any additional business rules not covered by the eligibility rules. Proper 
book and tax accounting for production packets occur and appropriate reports 
are generated. Finally, statistics for the packet are re-calculated in a process 
referred to as "roll-up". 

[0092] Packet dissolution arises from the same triggers as described with 
respect to packet modifications. In dissolving non-production packets, the 
underlying cash flows and assets have their status and conduit codes 
appropriately updated, and their links to the packet are removed. In essence, 
those cash flows are now available for use by another packet. The steps can 
include updating the status of underlying cash flows and assets, updating the 
conduit codes of underlying cash flows and assets, removing the cash flow link 
to the packet, marking the packet as having a state of Dissolved. 
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[0093] In an exemplary embodiment, the process of securitizing a packet 
occurs between the pending and production states and includes these 
functions: set-up and assigning of pool number and/or CUSIP, determination of 
issue date, settlement and issuance of the packet, accounting for production 
packets, and generating appropriate disclosure documentation and reports. 

[0094] Roll-up takes the information contained in the packet and calculates 
summary cash flows, investor payments, as well as statistics about the 
packet. An example list of attributes resulting from the roll-up function include 
the calculation of: UPB (unpaid principal balance of the packet), WAC 
(weighted-average coupon or note rate of underlying mortgage loans), WAM 
(weighted-average maturity of underlying mortgage loans), WALA (weighted- 
average loan age of underlying mortgage loans), WALT (weighted-average loan 
term at origination of underlying mortgage loans), and GEODIST (geographical 
distribution of underlying mortgage loans). Not all of these attributes may be 
appropriate and what is calculated depends on the packet type. For packets 
that represent securities, such calculations will facilitate investor disclosure on 
a periodic basis. 

[0095] Referring to FIG. 13, a packet creation system 290 is illustrated. In 
an exemplary embodiment, there are three main states that a packet can be in: 
a pre-packets state 292, a pending packets state 294, and a production 
packets state 296. Each of the saved versions is considered a pre-packet. 
Additionally, if a user sets up an Auto-Sift, the underlying cash flows that meet 
the sift criteria are placed in a pre-packet. 

[0096] When the user decides that a given pre-packet is to be securitized, 
he/she can move the packet into the pending packet state 244. If the pending 
packet meets all of the necessary criteria, it can then be moved to the 
production packet state 296. 

[0097] A pre-packet is a packet that has been created, but has not been 
confirmed as a pending packet or production packet. The cash flows or items 
contained in the packet are tagged as having a. status of Hold so that other 
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users are aware that the underlying items in the packet are being considered 
for production use. 

[0098] Items contained in a pre-packet have a Hold status. If an item is 
tagged as having a status of Hold, it is visible to other users while they model 
the packet. Additionally, the person and the date and time in which that item 
was placed on Hold are persisted and available through the user interface. 
However, the cash flow or item cannot have a Hold status to be included other 
packets. 

[0099] Under most circumstances, only the user that placed the cash 
flow/item on hold is allowed to remove the Hold status. However, in case of 
emergencies, a supervisor or designated super user can have "over-ride" 
capabilities to remove the Hold status. In this case, the user that placed the 
cash flow/item on hold is notified by email or page of this change. 

[0100] The pending packet state is the state right before a packet becomes 
a production packet. The purpose of the pending packet state is to lock the 
cash flows while necessary edits, checks, and approvals are being performed 
before the packet is ready to become a production packet. The underlying cash 
flows of a pending packet are labeled with a status of Locked, and are 
therefore not available in the Sift/Sort tool for inclusion in the creation of other 
packets. 

[0101] Items contained in pending packets have a Locked status. If an item 
is tagged as having a status of Locked, it is not be available for Sift/Sort and 
cannot be included in other packets. Items placed in a Locked status are 
limited in what can be done to them in that they are not available for Sift/Sort 
or Packeting. If an item belongs to a pending packet, it is possible to change 
the status from Locked to Hold or removing the Locked status altogether 
easily. 

[0102] A production packet can be considered the most restrictive of the 
three packet types. Like the name states, a production packet is a packet that 
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has been moved to production and has been securitized. The underlying cash 
flows of a production packet are labeled with a status of Locked, and are 
therefore not available for Sift/Sort. 

[0103] Editing and dissolving production packets can be detailed, complex, 
and secure transactions. In order to edit or dissolve a production packet, the 
user has special permissions and the transactions have multiple control points. 
The creation, editing and dissolution of production packets cause accounting 
events to occur. 

[0104] Items contained in the production packets state 296 have a 
Production status. If an item is tagged as having a status of Production, it is 
not available for Sift/Sort and cannot be included in other packets. Items 
placed in a Production status are limited in what can be done to them in that 
they are not available for sift/sort or packeting. Guidelines with regards to 
changing the status from Production following a dissolution or change to a 
production packet are governed by the rules of the packet type. 

[0105] If a packet is dissolved, its state is marked as Dissolved. Information 
as to the user, date and time that the packet was dissolved shall be stored. 
The effective dates are also stored, as this determines when the asset cash 
flows become available again. 

[0106] At time of packet creation, much packet data defaults to a 
transaction type that the packet is being created for. However, a packet 
structure that is able to identify and handle exceptions to these defaults is 
needed to accommodate custom transactions Packets have a minimum 
required set of attributes, along with a variety of additional attributes. Table II 
illustrates the kinds of data in an exemplary packet: 



-33- 



WO 2004/061553 



PCT/US2003/036867 



PACKET ITEM 


EXAMPLE DATA WHERE FROM? 


PACKET HEADER DATA 






Packet ID (unique) 


123456789 


qenerated 


Packet type 


MBS pool, meqa poo!, pseudopool, reference pool 


entered, trans mgr 


Packet creation date 


04/15/2002 


generated 


Packet status 


production, pendinq 


generated 


OPTIONAL PACKET HEADER DATA 




CUSIP number 


31359 


entered or trans mgr (Acq) ! 


trade date 


04/17/2002 


entered (SPAM only) 


settlement date j 


05/13/2002 


enierea (orMivi oniy; 


expected sale price ! 


99.524 


entered (SPAM only) 


prepayment model 


PSA, CPR 


selected (SPAM only) 


prepayment speed 


240 (PSA), 15 CPR 


entered (SPAM only) 


initial security PTR 


7.00% 


selected (SPAM), entered (Acq) 


trade number 


605288B 


entered (orAM only) 


business rules applied at creation 


(as numbered in Acq business rules library) 


packet creation 


data as of date at creation 


03/31/2002 


packet creation 


book cost basis 


99.12345 (price), $123,456,789.01 (dollar value) 


packet creation (SPAM) 


tax cost basis 


99.12345 (price), $123,456,789.01 (dollar value) 


packet creation (SPAM) 








PACKET DATA USE MAP 






asset ID 


loan number 123456789012, packet number 9876543210 


packet creation 


asset type 


loan, packet 


packet creation 


data element 1 


scheduled principal, net PTR interest, qross GF, excess SF, UPB 


packet creation 


cashflow quantity 1 


57.12345678%, 17.34 bps, $12.50 


packet creation 


disclosure basis quantity 1 


100.00% 


packet creation 


data element 1 effective date in 




substitution only 


data element 1 effective date out 




substitution only 


NOTF: There mav he manv iterations of data element+auantitv for an v one asset, and many assets. 








PERIODIC PROCESS DATA 






rollup frequency 


monthly, quarterly, annual 


packet creation 


payment activity cut-off date 


calendar monthend, calendar quarterend, 15th, last business day 


packet creation 


payoff activinq cut-off date 


calendar monthend, calendar quarterend, 15th, last business day 


packet creation 


reportinq cut-off date 


since previous, preceedinq calendar month, preceeding year 


packet creation 


rollup business rules to apply 


(as numbered in SIR rules library) 


packet creation 










PACKET OUTPUT 






output report 1 


Bond Buyer, Quartiles, ARMAT, pseudopool, GEODIST, FLIP 


packet creation, entered 


output release date 


4th business day, calendar quarterend+3 business days 


packet creation 


public/private flag 


public 


entered 








Table II: Exemplary Packet Data 



[0107] Table II reflects that a packet may store several pieces of information 
pertaining to its creation, such as what business rules were applied. Note also 
that the packet references predefined reports (which are defined elsewhere), 
and supplies the basis for computation in those reports (e.g. use 100% of UPB 
when computing WAC and WAM in the ''Bond Buyer" report). 

[0108] Some packets are associated with loan-level cash flows. A packet 
(or in some cases a chain of packets) describes how the underlying loan assets 
are associated with a "finished" deal-related product. However, to be fully 
useful to downstream processes, some data decomposition (or "internal re- 
mapping") may have to be applied first. Some of the data decomposition steps 
can precede packet creation and rollup, converting loan level data reported by 
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lenders into a form useful to downstream processes. Data decomposition is 
not just related to packets; it is also necessary for accounting, analysis, and 
reporting. In cases where the internal use of lender reported inbound data 
differs from its use within a packet, data re-mapping is required for roll-up. In 
some cases, this re-mapping may occur on a transaction-specific basis, and 
therefore be a by-product of the same event that also resulted in the creation 
of a packet. It also is possible that re-mapping is required several times as an 
asset is associated with additional transactions over time, such as MBS to 
Mega to REMIC. 

[0109] Referring again to FIG. 13, when the decision is made to securitize a 
packet, the packet moves to the pending packet state 294 and the underlying 
assets get a status of Locked. A Pending Packet can be elevated to a 
Production Packet once all of the necessary steps have been taken. Assets 
remain Locked following a state change to Production. Alternatively, the 
packet could be dissolved, in which case the assets are freed up for another 
packet to use. Packet dissolution can also happen from the pre-packet state 
292. If an OOP Production Packet is dissolved, for example, its assets may 
become available for use by another packet. When lender-formed packets are 
dissolved, the assets are normally returned to the lender. 

[0110] If a user decides that he/she wishes to create a Packet, the user is 
allowed to create a pre-packet. The pre-packet places the underlying cash 
flows or items on Hold in addition to storing all of the information that is stored 
by a version defined above. Preferably, there is only be one pre-packet created 
for a given session. If a user decides that he/she wants to packetize a version 
that is being worked on, but he/she already has a pre-packet, he/she is asked 
to dissolve the previous pre-packet. Previously created pre-packets are 
dissolved before a version is available for packetization. Additionally, versions 
are allowed to view cash flows that have a Hold status if the Hold status was 
placed by a packet created in the same session. 
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III. Data Processing System 

[0111] Referring now to FIG. 14, a computer system 310 usable to 
implement the cash flow engine and packeting systems described above is 
shown. The computer system 310 is described in greater detail in "System 
and Method for Processing Data Pertaining to Financial Assets'' Atty. Dkt. No. 
037607-0158, filed simultaneously herewith, hereby incorporated by 
reference. 

[0112] As shown in FIG. 14, the system 310 comprises a data processing 
system 312, user systems 314, bulk data systems 316, and other data 
interfaces 318. The data processing system 312 further comprises user 
services logic 322, a transaction processor 324, underwriting logic 326, 
acquisition logic 328, servicer and investor reporting logic 330, securitization 
logic 332, common services logic 334, a data storage system 338, and other 
data interfaces 336. Although the term "logic" is used in connection with 
some blocks and the term "processor" is used in connection with other blocks, 
these two terms are used interchangeably. The term "processor" is used in the 
generic sense and is not meant to imply a separate discrete unit of processing 
hardware. 

[0113] The data processing system 312 is configured for processing data 
pertaining to financial assets, such as loans and securities. In one 
embodiment, the data processing system 312 is configured to be used by a 
participant in the secondary mortgage market. Herein, for convenience, the 
participant is referred to as a "purchaser," although it should be understood 
that the purchaser may participate in the secondary market in other, different, 
or additional ways (e.g., as a loan guarantor, as a loan securitizer, and so on). 

[01 14] The data processing system 31 2 is preferably usable to support 
various types of transactions which may be executed by such a purchaser in 
connection with one or more loans. For example, the purchaser may purchase 
loans from lenders or other loan originators as part of a cash execution. The 
purchased loans may, for example, be held as investments in the purchaser's 
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investment portfolio. Alternatively, the purchaser may create mortgage backed 
securities (MBS) as part of an MBS execution, or create other financial 
instruments or assets that are backed by cash flows associated with individual 
loans, including both loans that have been purchased by the purchaser and 
other loans that have not been purchased by the purchaser. For example, in 
the case of MBS, the purchaser may acquire a pool of loans, securitize the pool, 
of loans to create MBS that is then sold to investors, and hold the pool of 
loans in trust for the benefit of the investors. The purchaser may also receive 
a fee for guaranteeing to holders of MBS or other financial instruments the 
repayment of the loans by borrowers. The purchaser may also use loans to 
create other types of financial assets or instruments, for example, by 
purchasing loans and selling the financial instruments to investors, or by 
performing such services for other owners of loan assets. 

[0115] The acquisition logic 328 is preferably usable to perform such 
operations as receiving information such as loan term, interest rate, principal 
owed and other parameters regarding loans when loans are first purchased or 
otherwise acquired and entered into the data processing system 31 2. In the 
case of cash executions, the acquisition logic 328 is also used to perform such 
operations as receiving commitments for the purchased loans. 

[0116] The servicer and investor reporting logic 330 is used to perform loan 
accounting and generate accounting output in connection with the purchased 
loans. Herein, the terms "reporting logic" and "servicer and investor reporting 
logic" are used interchangeably and both refer to logic that is configured to 
perform loan accounting and generate accounting output (e.g., for purposes of 
investor reporting, for purposes of managing a loan portfolio, and so on) in 
connection with a plurality of loans. The servicer and investor reporting logic 
330 preferably performs such functions as receiving loan payment data on an 
ongoing basis from third party servicers. In this regard, it may be noted that 
the servicer and investor reporting logic 330 in the illustrated embodiment is 
not used for servicing loans directly but rather merely interfaces with loan 
servicing logic provided by a third party servicer. Of course, the servicer and 
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investor reporting logic 330 could also be configured to include additional logic 
for servicing loans, either as part of the servicer and investor reporting logic 
330 or as part of another functional block. The accounting output generated 
by the servicer and investor reporting logic 330 may include such things as 
accounting, tax, performance/valuation, and/or other relevant financial 
information for the loans in the portfolio. 

[0117] The servicer and investor reporting logic 330 includes loan process 
and compare (LPC) logic 340, which monitors and verifies the activities of third 
party mortgage servicers on an ongoing basis. The logic 330 includes logic 
that implements the accounting/reporting tools 17 of FIG. 1 . The LPC logic 
340 performs processing related to decomposing borrower payments into sub- 
loan level cash flows in accordance with the CFAS maps discussed above in 
connection with FIGS. 3-5. Thus, the LPC logic 340 performs such operations 
as receiving and validating reporting information pertaining to loan activity, 
loan delinquency information and unpaid balance comparison reported by the 
servicer, updating the records of the data processing system 31 2 regarding the 
status of all reported loans, and determining the remittance and disbursement 
amounts that are expected for the loans. The LPC logic 340 also computes 
and monitors cash flows entering into the packets. 

[0118] The servicer and investor reporting logic 330 also includes securities 
aggregation and management (SAM) logic 342 which receives the loan level 
cash flow information produced by the LPC logic 340 and aggregates this cash 
flow information to produce security level information and generate disclosure 
reports. The SAM logic 342 performs processing related to the PCFA maps 
discussed above in connection with FIGS. 5-7. The SAM logic 130 is capable 
of processing and managing any grouping of loans, cash flows from loans, and 
other financial instruments. Using a packet activity processor, the SAM logic 
342 determines the loans in a given pool, repackages cash flows based on the 
pool and loan level attributes for all the loans and then updates the system 
database. The packet activity processor has the flexibility to repackage loan 
level cash flows at the most granular level to security level enabling the SAM 
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logic 342 to also manage specific cash flow strips (e.g., access yield strips, 
interest only strips). At the end of appropriate processing periods, the SAM 
logic 342 finalizes the relevant security information. The SAM logic 342 then 
uses a packet disclosure processor to make final remittance level principal and 
interest, guaranty fee, and other draft amounts and security accounting data 
available to other components the data processing system 31 2. The SAM 
logic 342 also includes packet modification request processing logic which is 
used to modify packets. 

[0119] The securitization logic 332 is used to generate financial assets and 
includes logic that implements the decomposition/repackaging tool 1 6 
described above in connection with FIG. 1 . Herein, the terms "financial asset 
generation logic" and "securitization logic" are used interchangeably and refer 
to any logic that is used to generate/create financial assets. The securitization 
logic 332 may be used to generate financial assets such as MBS, debt 
instruments, or any of the other types of financial instruments described 
herein. The securitization logic 332 may be used to generate financial assets 
that are tracked internally in situations where the owner/operator of the data 
processing system 31 2 purchases a pool of loans and holds the loans as an 
investment in its own portfolio. 

[0120] The common services logic 334 includes a rules engine. The rules 
engine comprises a series of business rules used in decomposing and 
repackaging cash flows and performing other loan processing. 

[0121] Preferably, operators access the data processing system 312 through 
the Internet by using a personal/laptop computer or other suitable Internet- 
enabled device. For example, the data processing system 312 may be 
accessible to users by visiting an internal web site of the entity that performs 
the cash flow decomposition/repackaging (that is, the web site of the entity 
that owns/operates the data processing system 31 2, and that is assumed to be 
in the business of purchasing, guaranteeing, and/or securitizing loans) and 
clicking on appropriate links located at the web site. 
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[0122] It will be appreciated that the data processing system 312 may 
perform fewer or additional functions as compared to those described herein. 
For example, an entity that performs only some of the above-mentioned 
processes may use a computer system that contains only a subset of the 
functions described herein. 

[0123] The preferred data processing system 312 exhibits a high level of 
data, service and time granularity. With respect to data granularity, the system 
31 2 is capable of decomposing loans into a series of highly granular cash flows 
and tracking all of the cash flows from the point the cash flows enter the data 
processing system 312 {e.g., as part of a loan payment or other cash flow 
source) to the point the cash flows exit the data processing system 312 (e.g., 
as part of a payment on a financial instrument), as previously described. The 
decomposition and mapping of cash flows dramatically increases the number of 
different types of financial instruments that may be created, because it makes 
it possible to create financial instruments based on these other cash flows. In 
turn, this makes it possible to create financial instruments that are more 
optimally configured to meet the needs of the owner of the financial 
instrument. 

[0124] With respect to service granularity, the data processing system 31 2 
represents loans as a series of attributes and uses a business rules engine to 
process loan information. This dramatically simplifies the process of expanding 
the capabilities of the data processing system 31 2 to process data associated 
with new types of loans. The capability to process a new type of loan may be 
added by adding an additional attribute to a list of available attributes 
corresponding to the new product feature (or modifying existing attributes), by 
using the attribute to indicate the presence or absence (and/or other 
characteristics about the new feature) in a particular loan, and by modifying 
the rules engine may then be modified to incorporate additional rules regarding 
the new loan feature. It is not necessary to build a completely new data 
processing system for the new type of loan. This makes it easier to offer new 
types of loans which are more optimally configured to meet the needs of 
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individual borrowers. An exemplary set of attributes is described at the end of 
this section. 

[0125] With respect to time granularity, the data processing system 312 is 
capable of processing data using a much smaller time slice or update period 
than has been possible in the past. In the past, systems have typically been 
constructed around the assumption that servicers provide monthly reports 
which summarize loan activity that occurred during the previous month. The 
time slice for reporting has been one month and sub-monthly temporal data has 
been lost. In the data processing system 312, when information regarding 
new loans is received by the acquisition logic 328 and/or when information 
regarding loan payments is received by the servicer and investor reporting logic 
330, this information preferably includes information regarding the date the 
loan was acquired, the date or dates within each month or other period other 
period on which a payment or other transaction is expected, and/or the date 
the payment was received. The time slice in the data processing system 31 2 is 
therefore one day (or less, if a smaller time slice such as AM/PM, hour, 
minutes/ seconds, and so on, is used). The temporal information is stored and 
maintained in databases which are synchronized/commonly accessible by the 
acquisition logic 328, the servicer and investor reporting logic 330, and the 
securitization logic 332. As a result, the acquisition logic 328, the servicer and 
investbr reporting logic 330, and the securitization logic 332 each have access 
to this highly granular temporal information regarding loan acquisitions and 
payments. The increased time granularity supports the above-mentioned 
capabilities to offer a wider array of loans to borrowers and a wider array of 
financial instruments to investor. For example, the increased time granularity 
facilitates offering loan products in which the borrower is expected to make bi- 
weekly payments, which may be attractive to borrowers that get paid bi- 
weekly instead of twice-monthly or monthly. This also facilitates handling loan 
products in which the date of a transaction is meaningful, such as daily simple 
interest loans. Further, because sub-loan cash flows can be processed using a 
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one day time slice (or less), it is possible to create financial instruments based 
on cash flows that are processed on a per day basis. 

[0126] Another benefit of the acquisition logic 328, the servicer and investor 
reporting logic 330, and the securitization logic 332 being provided on a 
common platform and access common/synchronized databases is that each 
system has an up to date view of the data. As previously indicated, the data 
processing system 312 has the ability to accept payment and other transaction 
information from a servicer as such transactions occur (e.g., using daily, 
hourly, or near real-time updates) instead of or in addition to receiving end of 
the month summary transaction information from the servicer. Once the data 
is received, it is accessible throughout the data processing system 31 2. For 
example, it is not necessary to limit the data updates for the securitization logic 
to a once-per-month basis at the end of a servicing cycle. Therefore, an up to 
date view of the data is available throughout the data processing system 312. 

[0127] It should also be apparent that it is also possible to construct data 
processing systems which do not incorporate the advantages described herein 
in connection with the data processing system 312, or which also incorporate 
additional advantages not described herein. Further, it may also be noted that 
the separation of functionality shown in FIG. 14 is necessarily to some extent 
conceptual, and it is also possible to provide the same functionality in other 
ways. Additionally, although numerous functions are described below, it may 
be noted that it may be desirable to provide fewer, additional, or different 
functions in a given data processing system depending on the application and 
what is needed. 

[0128] Throughout the specification, numerous advantages of preferred 
embodiments have been identified. It will be understood of course that it is 
possible to employ the teachings herein without necessarily achieving the same 
advantages. Additionally, although many features have been described in the 
context of a particular data processing system, it will be appreciated that such 
features could also be implemented in the context of other hardware 
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configurations. Further, although various figures depict a series of steps which 
are performed sequentially, the steps shown in such figures generally need not 
be performed in any particular order. For example, some of the steps may be 
performed essentially simultaneously. Additionally, some steps shown may be 
performed repetitively with particular ones of the steps being performed more 
frequently than others. Alternatively, it may be desirable in some situations to 
perform steps in a different order than shown. 

[0129] While the exemplary embodiments illustrated in the figures and 
described above are presently preferred, it should be understood that these 
embodiments are offered by way of example only. Other embodiments may 
include, for example, structures with different data mapping or different data. 
The invention is not limited to a particular embodiment, but extends to various 
modifications, combinations, and permutations that nevertheless fall within the 
scope and spirit of the appended claims. 
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WHAT IS CLAIMED IS: 

1 . A packet that packages cash flows from financial instruments, the 
packet comprising: 

packet description data having creation, purpose, and transaction 
information data describing the packet; 

a data map including information on cash flows that flow into the 
packet; and 

process instructions including information on cash flow processing for 
the cash flows that flow into the packet. 

2. The packet of claim 1, wherein the header data, data map, and 
process instructions decouple inbound cash flows from, outbound cash flows, 
thereby accommodating transactions with indirect segregation of cash flows. 

3. The method of claim 2,;wherein transactions with less direct 
segregation of cash flows include structured transactions. 

4. The method of claim 2, wherein transactions with less direct 
segregation of cash flows include transactions having cash flows in a non-fixed 
format. 

5. The packet of claim 1, wherein header data includes packet type 
information indicating the type of cash flow associated with the packet. 

6. The packet of claim 1 , wherein the packet is created in 
accordance with business rules. 1 

7. The packet of claim 1, further comprising an indication of a packet 

state. 

8. The method of claim 7, wherein the packet state is capable of 
being any of the following packet states: pre-packet, pending packet, and 
production packet. 
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9. The method of claim 1, wherein sources of cash flows include any 
one of loan remittances, percentages of loan remittances, pool distributions, 
and securities. 

10. A method of creating a packet, the method comprising: 
selecting assets; 

applying business rules to the selected assets; 

mapping cash flows associated with the selected assets; and 

applying packet creation rules to form at least one packet. 

1 1 . The method of claim 10, further comprising modifying the at least 

one packet. 

/ 

1 2. The method of claim 1 1 , wherein modifying includes removal, 
substitution, or addition of cash flows. 

13. The method of claim 10, wherein the at least one packet 
comprises attributes, including packet type, packet state, set of assets, 
underlying asset type, allocation of each asset cash flow to be included in the 
packet, and effective dates for each cash flow. 

14. The method of claim 10, wherein mapping cash flows associated 
with the selected assets comprises using a graphical user interface (GUI) in 
which specific sources of cash flow can be selected and quantities of cash 
flow can be added to the packet. 

15. The method of claim 10, wherein mapping cash flows associated 
with the selected assets comprises using a template by transaction type to set 
default values in the packet. 

16. A system that packages cash flows from financial instruments, 
the system comprising: 

means for selecting assets; 

means for applying business rules to the selected assets; 

-45- 



WO 2004/061553 



PCT/US2003/036867 



means for mapping cash flows associated with the selected assets; and 
means for applying packet creation rules to form at least one packet. 

17. The system of claim 16, further comprising means for modifying 
the at least one packet. 

1 8. The system of claim 1 6, wherein the at least one packet 
comprises header data, a data map, and process instructions. 

1 9. The system of claim 1 8, wherein the at least one packet further 
comprises business rules for processing cash flows and creating packets. 

20. The system of claim 16, wherein means for mapping cash flows 
associated with the selected assets comprises means for selecting cash flow 
sources ^nd quantities to be added to the at least one packet. 

21 . A data construct for representing a financial asset in a data 
processing system, comprising: 

description data having creation, purpose, and transaction information 
data describing the financial asset; 

a cash flow map including information on cash flows that flqw into the 
financial asset; and 

process instructions including information on cash flow processing for 
the cash flows that flow into the financial asset. 
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Examples of Possible Packet Content 



Data 
Use Map 



Periodic 
Process 
Data 



Output 



MBS PACKET 



MEGA PACKET 



Asset Identifier 


923456789 


Asset Type 


loan 


Data Element scheduled_UPB 


Cashflow Quantity 


55.0000% 


Disclosure Basis Quantity 


100.0000% 


Effective Date In 


04-30-2002 


Effective Date Out. 





.258 



270 - 



L 



L 



Rollup Frequency Monthly 
Payment Activity Cutoff 25th 
Payoff Activity Cutoff EOM 
Reporting Cutoff Trading Factor Date 
Rollup business rules 4,7,12,16,28 



Output report 


Bond Buyer 




Public/private 


public 




Release Date 


4th Business Day 





260 
272 
262 



274 



Header 
(standard) 


Packet Identifier 
Packet Type 
Packet Creation Date 
Packet Status 


123456789 
MBS pool 
04-15-2002 
production 


^254 

266 ^ 


Packet Identifier 
Packet Type 
Packet Creation Date 
Packet Status 


6677868 
Mega 
05-18-2002 
pending 


Header 
(optional) 


Cusip 
Trade Date 
Settlement Date 
Expected Sales Price 
....etc. 


31359FAKE 

04- 17-2002 

05- 13-2002 

99.524 


^256 

268- 


Cusip 
Trade Date 
Settlement Date 
....etc. 


5449PRND 

05- 20-2002 

06- 16-2002 



Asset Identifier 




123456789 


Asset Type 




MBS 


Data Element 


scheduledJJPB 


Cashflow Quantity 




100.0000% 


Disclosure Basis Quantity 


100.0000% 


Effective Date In 




05-30-2002 


Effective Date Out. 







Rollup Frequency Monthly 
Payment Activity Cutoff 25th 
Payoff Activity Cutoff EOM 
Reporting Cutoff Trading Factor Date. 
Rollup business rules 4,7,12,16,28 





Output report 


Bond Buyer 




Public/private 


public 




Release Date 


4th Business Day 
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